1. Avant-propos
1.1. About Papyrus
-
Tool for defining UML-based DSLs
-
UML profiles
-
Support for customizability
-
Open, robust, highly scalable
-
Model-Driven Egineered (written using Papyrus itself)
-
-
More details:
Figure 1. https://www.eclipse.org/papyrus/
1.2. About the modelers
People from CEA-List involved in this case study (special thanks):
Project involvment (3.5 days):
-
metamodel + profil ⇒ 1d
-
customization ⇒ 2d
-
example farming model ⇒ 0.5d
2. Profile-based approach
Contribution by Saâdia Dhouib, Florian Noyrit, Jean-Michel Bruel.
2.1. What is a profile ?
-
Abstract syntax for a new language
-
Set of stereotypes
-
Set of OCL constraints
-
2.2. General process
The idea behing this approach is that there will be some benefits in the use of the UML standard. Hence the DSL will be based on UML by using the profile mechanisms.
As illustrated in this figure, here is the processus we can follow:
- Step #1
-
Starting from the expected DSL (most of the time a
modelscor a graphical représentation) and a description of the domain model (modelmde)
- Step #2
-
A domain modelmde is more precisely defined (e.g. a class diagram such as Main concepts of the domain model)
activities- Step #3
-
The concepts (e.g.,
Farmin Main concepts of the domain model) are mapped to the more suitable UML elements (e.g.,Classin Mapping concepts with UML metamodel to define a profile)
- Step #4
-
If the concepts directly match UML concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., Mapping concepts with UML metamodel to define a profile)
- Step #5
-
Else another solution (e.g., defining a metamodel from scratch) should be studied.
- Step #6
-
It is time then to "customize" the DSML to make it as close as possible as the user domain representation.
|
Note
|
There are different ways of defining the domain model:
|
2.3. Iterative process
The above process is iterative. The constructs are introduced by step.
The profile is experimented in a modelsc importing the profile so that the user can validate
that the concepts are captured adequatly.
This is were the UML expert can use tuning possibilities.
2.4. Improvements
The next steps can consist in:
-
defining a dedicated diagram
-
providing a wizard for the new language
-
defining a specific property view ( and then right click on the generated property)
-
Working on the concrete syntax:
-
customizing the styles (look & feel)
-
customizing
-
customizing the Model explorer
-
packaging together the profile, the property view, the palette, etc.
-
|
Tip
|
|
2.5. Example of work on the concrete syntax
Let us illustrate the need for a specific concrete syntax.
2.5.1. Structural Domain Model
2.5.2. Functional Domain Model
2.5.3. Structural profile
2.5.4. Functional profile
2.5.5. Using the profile: Farm structure
2.5.6. Using the profile: Papyrus context
2.5.7. Crop Workshops description
2.5.8. Activity description (UML Activity Diagram)
2.5.9. Activity description (UML Activity Diagram)
2.5.10. Customizing the Model Explorer
2.5.11. Customizing the Palette (structure)
2.5.12. Customizing the Palette (activities)
2.5.13. Customizing the Palette (property view, structural element)
2.5.14. Customizing the Palette (property view activity element)
2.5.15. Animation and external tools coupling
3. Conclusion
3.1. Profile definition
-
in terms of stereotypes (extending metaclasses)
-
adding specific properties to the stereotype (e.g.,
periodin this figure) -
adding OCL constraints
3.2. Main differences
-
Using
ecore-
the process consists in starting from scratch, from an empty metamodel
-
the domain model is then define by construction
-
-
In the
UML profileapproach-
we start with an existing (complete) metamodel
-
and the profiling activity consist in restricting it to specific elements
-
the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of
-
extensibility mecanisms
-
scalability
-
-
3.3. (honest) Feedbacks
-
Easy tuning and customizing possibilities
-
Almost like doing regular UML modeling
-
UML good knowledge required
-
Not trivial
-
Great work from CEA (3.5 days of work)
-
Need close loop with the client (agile manifesto)
3.4. DSML from scratch: the "Wysiwyg approach"
-
No constraint on what we type
-
Immediate visualization of the result
-
Possibility to have templates
-
More and mode styles and quality
3.5. DSML as UML profiles: the "LaTeX approach"
-
Constrained language
-
No immediate visualisation of the result
-
Naturally based on templates
-
Rich in libraries and styles
-
Possibilities to see what you get on (almost) real-time
-
Collaborative and user-friendliness improvements
About…
Photo credits: